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(54) Metadata model 

(57) A metadata model defines model objects to 
represent one or more data sources. The metadata 
model comprises a data access layer, a business layer 
and a package layer. The data access layer contains 
data access model objects. The data access model ob- 
jects include a data access model object that describes 



how to retrieve data from the data sources. The busi- 
ness layer contains business nrxxiel objects. The busi- 
ness rrKxiel objects include a business wode\ object that 
describes a business view of data in the data sources. 
The package layer contains package nrKxJel objects 
which reference subsets of business model objects. 
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Description 

HELD OF THE INVENTION 

[0001] The present invention relates generally to a 
metadata model, and more particularly to a metadata 
model which is suitably used in a reporting system that 
access a plurality of data stores including relational da- 
tabases. 

BACKGROUND OF THE INVENTION 

[0002] It is known to use data processing techniques 
to design information systems for storing and retrieving 
data. Data is any infonDation, generally represented in 
binary, that a computer receives, processes, or outputs. 
A database or data warehouse is a shared pool of inter- 
related data, tnfomriation systems are used to store, nna- 
nipulate and retrieve data from databases. 
[0003] Traditbnally. file processing systems were of- 
ten used as information systems. File processing sys- 
tems usually consist of a set of files and a collection of 
application programs. Permanent records are stored in 
the files, and application programs are used to update 
and query the files. Such application programs are gen- 
erally developed Individually to meet the needs of differ- 
ent groups of users. Information systems using ^file 
processing techniques have a number of disadvantag- 
es. Data is often duplicated among the files of different 
users. The lack of coordination between files belonging 
to different users often leads to a lack of data consist- 
ency. Changes to the underlying data requirements usu- 
ally necessitate major changes to existing application 
programs. There is a lack of data sharing, reduced pro- 
gramming productivity, and increased program mainte- 
nance. File processing techniques, due to their inherent 
difficultie s and lack of flexibility, have k^st a great deal 
of their popularity and are being replaced by database 
management systems (DBMSs). 
[0004] A DBMS is a software system for assisting us- 
ers to create reports from data stores by alk>wing for the 
definitk)n. constructk>n, and manipulation of a database. 
The main purpose of a DBMS system is to provide data 
independence, i.e., user requests are made at a logical 
level without any need for knowledge as to how the data 
is stored in actual files in the database. Data irKlepend- 
ence implies that the internal file structure could be mod- 
ified without any change to the users' perception of the 
database. However, existing DBMSs are not successful 
in provkJing data independence, and requires users to 
have knowledge of physical data structures, such as ta- 
bles, in the database. 

[0005] To achieve better data independence, it is pro- 
posed to use three levels of database abstractbn in 
"The Electrk:al Engineering Handbook' Richard C. Dorf, 
CRCnetBASE 1999, sectk)n 94.1. With respect to the 
three levels of datat)ase abstractkxi, reference is made 
to Figure 1. 



[0006] The bwest level in the database abstraction is 
the internal level 1 . In the internal level 1 , the database 
is viewed as a collectbn of files organized according to 
an intemal data organization. The internal data organi- 
5 zation may be any one of several possible intemal data 
organizatbns, such as B^-tree data organization and re- 
lational data organization. 

[0007] The mkJdle level in the database abstractbn is 
the conceptual level 2. In the conceptual level 2, the da- 

10 tabase is viewed at an abstract level. The user of the 
conceptual level 2 is thus shielded from the internal stor- 
age details of the database viewed at the intemal level 1 . 
[0008] The highest level in the database abstraction 
is the external level 3. In the extemal level 3, each group 

15 of users has their own perception or view of the data- 
base. Each view is derived from the conceptual level 2 
and is designed to meet the needs of a particular group 
of users. To ensure privacy and security of data, each 
group of users only has access to the data specified by 

20 its particular view for the group. 

[0009] The mapping between the three levels of da- 
tabase abstraction is the task of the DBMS. When the 
data structure or file organization of the database is 
changed, the intemal level 1 is also changed. When 

25 changes to the internal level 1 do not affect the concep- 
tual level 2 and external level 3, the DBMS is sakJ to 
provkie for physical data independence. When changes 
to the conceptual level 2 do not affect the extemal level 
3, the DBMS is said to provide for logbal data independ- 

30 ence. 

[0010] Typbal DBMSs use a data model to describe 
the data and Its structure, data relationships, and data 
constraints in the database. Some data models provide 
a set of operators that are used to update and query the 

35 database. DBMSs may be classified as either record 
based systems or object based systems. Both types of 
DBMSs use a data model to describe databases at the 
conceptual level 2 arKf external level 3. 
[0011] Data models may also be called metadata 

40 models as they store metadata, i.e., data about data in 
databases. 

[0012] Three main existing data models used in 
record based systems are the relatbnal model, the net- 
work model and the hierarchbal model. 

45 [0013] In the relational model, data is represented as 
a collection of relatkms. To a large extent, each relation 
can be thought of as a table. A typbal relatkxial data- 
base contains catalogues, each catabgue contains 
schennas, and each schema contain tables, views, 

50 stored procedures and synonynr^s. Each table has col- 
umns, keys and indexes. A key is a set of columns 
whose composite value is distinct for all rows. No proper 
subset of the key is allowed to have this property. A table 
may have several possible keys. Data at the conceptual 

55 level 2 is represented as a collectbn of interrelated ta- 
bles. The tables are normalized so as to minimize data 
redundancy and update anomalies. The relatbnal mod- 
el is a logical data structure based on a set of tables 
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having common keys that allow the relationships be- 
tween data items to be defined without considering the 
physical database organization. 
[0014] A known high level conceptual data model is 
the Entity-Relatbnship (ER) model. In an ER model, da- 
ta is described as entitles, attributes and relationships. 
An entity is anything about whk:h data can be stored. 
Each entity has a set of properties, called attributes, that 
describe the entity. A relationship is an association be- 
tween entities. For example, a professor entity may be 
described by its name, age, and salary and can be as- 
sociated with a department entity by the relatbnship 
"works for'. 

[0015] Existing informatk>n systems use business in- 
telligence tools or client applicatksns that provide data 
warehousing and business decision making and data 
analysis support services using a data model. In a typ- 
ical information system, a business intelligence tool is 
conceptually provided on the top of a data nrKxIel, and 
underneath of the data model is a database. The data 
model of existing information systems typically has lay- 
ers correspoTKling to the external level 3 and the internal 
level 1 . Some data models may use a layer correspond- 
ing to both the external level 3 and the conceptual level 
2. 

[001 6] Existing data nxxlels are used for the concep- 
tual design of databases. When a system designer con- 
structs an information system, the designer starts from 
a higher abstraction level 3 and moves down to a lower 
abstraction level 1 , as symbolized In Figure 1 by arrows. 
[001 7] That is, the system designer first performs log- 
ical design. At the logk:al design stage, the designer 
considers entities of interest to the system users and 
identifies at an abstract level Information to be recorded 
about entities. The designer then determines conceptu- 
al scheme, i.e., the extemal level 3 and/or conceptual 
level 2 of a data model. After the bgbal design Is com- 
pleted, the designer next performs physical design. At 
the physk^al design stage, the designer decides how the 
data is to be represented in a database. The designer 
then creates the corresponding storage scheme, i.e., 
the structure of a database, and provkles mapping be- 
tween the internal level 1 of the data model and the da- 
tabase. 

[0018] Existing business intelligence tools thus each 
provides a different paradigm for retrieving and deliver- 
ing informatkxi from a database. Accordingly, it Is diffi- 
cult to share informatkyi in the database among different 
business intelligence tools. 

[0019] It is comrrion that in a single organizatk)n, each 
group of users has its own established information sys- 
tem that uses its corresponding datat>ase. Thus, the sin- 
gle organization often has multiple databases. Those 
databases often contain certain types of information 
which are useful for multiple groups of users. Such types 
of information may include information about business 
corrcepts, data retrieval, and user limits and privileges. 
However, each Informatkxi system was designed and 



constructed in accordance with specific needs of the 
group, and may use a different business intelligence tool 
from others. These differences in the information sys- 
tems and business intelligence tools used do not allow 

s sharing the informatkxi already existing in the databas- 
es among multiple groups of users. 
p)020] Accordingly, it is desirable to provide a data 
model or metadata model whk;h can realize the three 
abstraction levels and provkie informatbn that can be 

10 shared by multiple users who use those different busi- 
ness intelligence tools or client applbatbns. 

SUMMARY OF THE INVENTION 

15 [0021] The present invention provides a metadata 
model that have three layers of different abstractbn lev- 
els. 

[0022] According to one aspect of the present inven- 
tion, there is provided a metadata model that defines 

20 model objects to represent one or more data sources. 
The metadata model comprises a data access layer, a 
business layer and a package layer. The data access 
layer contains data access model objects. The data ac- 
cess model objects include a data access model object 

2S that describes how to retrieve data from the data sourc- 
es. The business layer contains business model ob- 
jects. The business model objects include a business 
model object that describes a business view of data in 
the data sources. The package layer contains package 

30 model objects. The package rrKxiel objects include a 
package model object which references a subset of 
business model objects. 

[0023] According to another aspect of the present in- 
vention, there is provkjed a metadata model that con- 

35 tains model objects representing one or more data 
sources. The data sources contain tables having col- 
umns. The metadata model comprises a data access 
layer, a business layer and a package layer. The data 
access layer contains data access model objects. The 

40 data access model objects include table objects that de- 
scribe definitions of the tables contained in the data 
sources, and column objects that describe definitbns of 
the columns of the tables contained in the data sources. 
The business layer contain business model objects. The 

45 business model objects include entities that are con- 
structed based on the table objects in the data access 
layer, and attributes that are constructed based on the 
column objects in the data access layer. The package 
layer contains package model objects. The package 

50 model objects include a package model object that ref- 
erence a subset of the business model objects. 
[0024] Other aspects and features of the present in- 
vention will become apparent to those ordinarily skilled 
in the art upon review of the following description of spe- 

55 cific embodiments of the invention in conjunctbn with 
the accompanying figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0025] Embodiments of the invention will now be de- 
scribed with reference to the accompanying drawings, 
in which: 

Figure 1 is a diagram showing an example of data- 
base abstractions; 

Figure 2 is a diagram showing an example of a re- 
porting system to which an embodiment of the 
present invention is applied; 
Figure 2A is a diagram showing functions of the 
metadata exchange, metadata nrxxjel and transfor- 
mations shown in Figure 2; 
Figure 2B is a diagram showing examples of objects 
contained in the metadata nrKxlel shown in Figure 
2; and 

Figure 3 is a diagram showing an example of a que- 
ry engine that uses the metadata nrxxJel shown in 
Figure 2. 

DETAILED DESCRIPTION OF EMBODIMENTS OF 
THE INVENTION 

[0026] Figure 2 illustrates a reporting system 4 to 
which an embodiment of the present invention Is suita- 
bly applied. The reporting system 4 provides a single 
administration point for metadata that supports different 
business intelligence tools or client applications. Thus, 
it enables different business intelligence tools to extract 
and interpret data from various data sources in the same 
way. 

[0027] The reporting system 4 includes common ob- 
ject se wices (COS) 5, a metadata exchange 1 0, a meta- 
data model 15, a metadata model transformer or trans- 
formations 20, a user interface 25 and a query engine 
30. The fundamental objective of the reporting system 
4 is to provide a rich business-oriented metadata nrKxiel 
15 that albws the query engine 30 to generate the best 
queries of which it is capable, and allows users to build 
queries, reports and cubes with the aid of the query en- 
gine 30 to obtain desired reports from underlying data 
sources. To this end, COS 5. metadata exchange 10and 
transformations 20 are provided. 
[0028] Prior to describing the metadata model 1 5 and 
the transformations 20 in detail, each element of the re- 
porting system 4 is briefly described. 
[0029] COS 5 defines the framework for object per- 
sistence. Object persistence is the storage, administra- 
tion and management of objects on a physical device 
and transfer of those objects to and from menrK>ry as 
well as the management of those objects on the physical 
device. The double head arrow from COS 5 in Figure 2 
represents that COS 5 communicates with all other el- 
ements shown in Figure 2. COS 5 performs functions 
such as creating new objects, storing them on disk, de- 
leting them, copying them, moving them, handling 
change isolatk>n (check-in, check- out) and object mod- 



elling. COS 5 uses a modelling language, such as Com- 
et Modelling Language (CML) that generates C++ code. 
[0030] The metadata exchange 10 is used to obtain 
metadata from external physical sources. Metadata is 

s obtained from one or more external sources of metada- 
ta. As shown in Figure 2A, external sources of metadata 
may be one or more data sources 100 and/or one or 
more metadata sources 101 . Data sources 1 00 contain 
physical data. Examples of data sources 1 00 include da- 

10 tabases and files. Metadata sources 101 contain de- 
scriptive information about data sources. Metadata 
sources 101 are also known as metadata repositories. 
Metadata repositories may be third party repositories. 
Metadata sources 101 generally have urtdertying data 

15 sources 1 00 containing physical data. The metadata ex- 
change 10 facilitates importatkxi of metadata from ex- 
ternal sources 100 and 101 Into the metadata model 15. 
Also, the metadata exchange 10 may facilitates expor- 
tation of metadata from the metadata model 15 to.ex- 

20 ternal metadata repositories. 

[0031 ] The metadata model 1 5 stores metadata about 
its underlying one or more dat a sources 100. It is used 
to provide a comnrK>n set of business- oriented at)strac- 
tions of the underlying data sources 100. The metadata 

25 model 1 5 defines the objects that are needed to define 
client applications that users build. The metadata model 
15 provides three layers to realize three levels of ab- 
stractions of data sources 100 as described atx)ve re- 
ferring to Figure 1 . The three layers are a physical layer 

30 or data access layer 102, a business layer 104 and a 
presentation layer or package layer 106. 
[0032] Transformations 20 are used to complete the 
metadata model 15. For example, when a database is 
introduced to the reporting system 4, metadata is im- 

35 ported from the database into the metadata model 15, 
Metadata may also be imported from one or more meta- 
data repositories or other data sources. Sufficient meta- 
data may be Imported from a database that wouki bulkJ 
only a small number of the objects that would actually 

40 be needed to execute queries. However, if such meta- 
data does not have good mapping to the metadata mod- 
el 15, then the transformations 20 can be used to pro- 
vide the missing pieces to complete the metadata model 
15. 

45 [0033] The user interface 25 is layered on top of the 
metadata model 1 5 as a basic maintenance facility. The 
user interface 25 provkies users with the ability to 
browse through the metadata model 1 5 and manipulate 
the objects defined thereby The user interface 25 is also 

so a point of control for the metadata exchange 1 0, for ex- 
ecuting transformations 20, and for handling check- in. 
check-out of nrKxJel objects, i.e., changed information, 
as well as a variety of other administrative operatkxi. 
The user interface 25 allows users for the performance 

ss of basic maintenance tasks on the objects in the meta- 
data model 15, e.g., changing a name, descriptive text, 
or data type. The user interface 25 is a mechanism that 
Involves the capabilities of the metadata exchange 10 
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and the transformatbns 20. The user interface 25 has 
the ability to diagram the metadata model15, so that the 
user can see how objects are related. 
[0034] The query engine 30 Is responsible for taking 
the metadata model 15 and a user's request for infor- 
mation, and generating a query that can be executed 
against the underlining data sources, e.g., a relational 
database. The query engine 30 is basically the reason 
for the existence of the rest of the blocks. The objective 
of the query engine 30 is to function as efficiently as pos- 
sible and to preserve the semantics of the original ques- 
tk>n. A user may ask a question that Is not precise. The 
request may be for something from ■customers' and 
something from "products*. But these may be related In 
multiple ways. The query engine 30 needs to figure out 
which relatbnship Is used to relate "customers* and 
"products" to provide the user with information request- 
ed. 

[0035] The use of the metadata model 1 5 by the query 
engine 30 is briefly described with reference to Figure 
3. A user uses a business intelligent tool or client appli- 
cation (not shown) to generate a user's request for in- 
formation. Upon the receipt of the user's request, the 
client application generates an initial specification 35 
based on the request. The specification 35 may be am- 
biguous. Also, It in not in a form that can be applied to 
the data sources directly. Using the informatk)n that is 
built In the metadata model 15, the query engine 30 
makes the specification 35 unambiguous and builds a 
query In terms of the data access layer 1 02 for the spec- 
ification 35. This Intermediate fonmulation of the query 
is also called a physical queiy and is subsequently 
translated into a data source specification language. 
The data source specification language nnay be Struc- 
tured Query Language (SQL). A query in a data source 
speclflcatk)n language can be executed on the data 
sources. Thus, the correct data 40 may be obtained. 

Metadata Model 15 

[0036] The metadata model 1 5 Is a tool to supply the 
common metadata administratk)n tool, unified and cen- 
tralized modelling environment, and applicatkxi pro- 
gram interfaces for business intelligence tools. The ar- 
chitecture of the metadata model 15 will now be de- 
scribed in further detail. 

[0037] Metadata contained in the metadata model 1 5 
Is also called model objects. The metadata model 15 is 
organized as a single containment tree or a series of 
containment trees. A containment tree starts at the high- 
est level with a model object. The nrKxJel object itself Is 
at the root of the tool, and all other objects, except the 
relationship objects, are contained within this root ob- 
ject. 

[0038] Figure 2B shows the architecture of the meta- 
data model 1 5. The metadata model 1 5 is composed of 
several layers, namely, a physical layer or data access 
layer 102, a business layer 104 and a presentation layer 



or package layer 106. These layers correspond to those 
abstraction levels shown In Figure 1 . 
[0039] The model objects contained In a higher ab- 
stractbn layer may Include objects whk:h are oonstruct- 
s ed from a lower abstraction layer to the higher abstrac- 
tion layer 

[0040] The data access layer 1 02 contains metadata 
that describes how to retrieve physical data from data 
sources 100. It is used to formulate and refine queries 

10 against the underlying data sources 1 00. The underlying 
data sources 1 00 may be a single or multiple data sourc- 
es, as described above. Examples of data sources 100 
include relatk>nal databases, such as Oracle, Sybase, 
DB2, SQL Server and Informix. 

IS [0041] The data access layer 102 contains a part of 
the model objects that directly describe actual physical 
data in the data sources 100 and their relatk)nships. 
These model objects may be called data access model 
objects. The data access model objects may Include, 

20 among other things, databases, catabgues, schemas. 
tables, files, columns, data access keys, indexes and 
data access joins. Each table has one or more columns. 
Data access joins exist between tables. A data access 
key corresponds to a key In the data sources 100 that 

25 references one or more column names whose compos- 
ite value Is distinct for all rows In a table. A data access 
join is a relationship between two or more tables or files. 
Also, the data access model objects may include views, 
function stored procedures and synonyms, If applicable. 

30 [0042] The data access rrKXiel objects In the data ac- 
cess layer 102 are metadata, which are created as a 
result of importing metadata from data sources 1 00 and 
metadata sources 101 provkJed by users. Examples of 
metadata sources 101 include Impromptu Catalogue 

35 and Impromptu Web Query 2.12. The infornrration of 
some data access objects may be available from the un- 
derlying data sources 100. Informatkxi for join relatk^n- 
ships are not available from the underlying data sources 
100. The user can customize some objects in the data 

40 access layer 1 02 in order to create data access joins, i. 
e., relatbnshlps between objects that were imported 
from various data sources. Also, the translonmations 20 
may transform the data access layer 1 02 to complete it. 
[0043] Also, the data access layer 1 02 may alk>w us- 

45 ers to define therein data source queries, such as SQL 
queries. Data source queries return a result set of phys- 
bal data from underlying data sources 100. Those cre- 
ated data source queries are treated as objects in the 
data access layer 1 02 like tables. After data source que- 

50 lies are defined, a set of columns objects is generated 
for each data source query by the query engine 30 
based on the SQL statement. Users may also define 
stored procedures and/or overloaded stored proce- 
dures, rather than Importing them from metadata sourc- 
es es101. 

[0044] Thebusiness layer 104 describes the business 
view of the physk:al data In the underlying data sources 
100. It is used to provide business abstractbns of the 
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physical data with which the query engine 30 can for- 
mulate queries against the underlying data sources 1 00. 
[0045] The business layer 104 contains a part of the 
model objects that can be used to define in abstract 
terms the user's business entities and their inter rela- 
tionships. These rrKxJel objects may be called business 
model objects. The business model objects are reusa- 
ble objects that represent the concepts and structure of 
the business to be used in business intelligence envi- 
ronments. They represent a single business mo6e\, al- 
though they can be related to physical data in a number 
of different data sources 100. 

[0046] The business model objects consist of a busi- 
ness nrKxJel, business rules and display rules. The busi- 
ness model may include entities, attributes, keys and 
joins. Joins may be also called join relationships. The 
user Interface 25 can provide a view of the business 
model as an entity-relationship diagram. The business 
rules may include calculations, fitters and prompts. The 
display rules may include elements, styles and enumer- 
ation values. 

[0047] The business model objects are closely related 
to the data access model objects in the data access lay- 
er 102. For example, entities in the business layer 104 
are related to tables in the data access layer 102 indi- 
rectly; and attributes In the business layer 104 corre- 
spond to columns in the data access layer 102. Busi- 
ness joins exist between entities. Each business nrxxiel 
object has a partner in the data access layer 102, i.e., 
a relationship exists between a table and an entity. While 
the tables in the data sources 1 00 store data access lay- 
er objects in accordance with the design of its underlying 
data sources 100. the entities in the business layer 104 
hold the metadata representing the business concept. 
Entities are collections of attributes. 
[0048] Attributes of entities in the business layer 104 
contain expressions related to columns of tables in the 
data access layer 102. An attribute is usually directly 
related to a single column of the data access layer 102. 
For example, the entity "customer" could have attributes 
'customer name", "customer address", and the like. In 
the simplest case, all the attributes of an entity in the 
business layer 104 are related one-to-one to the col- 
umns of a single table in the data access layer 1 02. How- 
ever, the relationship is not always a one - to-one rela- 
tionship. Also, an attribute may be expressed as a cal- 
culatbn based on other attributes, constants and col- 
umns. For example, an attribute may be a summary of 
data in other attributes, e.g.. a total amount of all the 
orders placed by customer. 

[0049] In the business layer 104, entities are related 
to other entities by joins. Joins are classified as one of 
containment, reference or association. A containment 
join represents a strong relationship between entities. 
For example, an entity Order Detail would have no 
meaning without an entity OrderHeader. Thus, the entity 
OrderDetail Is containment of the entity OrderHeader. 
[0050] A reference join indicates that one entity acts 



as a kx)kup table with respect to the other For example, 
OrderDetail and Products are related via a relationship. 
In this case, Products acts as a lookup table so the re- 
lationship is marked as a reference relationship. 
s [0051] An association join represents relatbnships 
between entities whk;h are not categorised as contain- 
ment or reference joins. 

[0052] It is advantageous to categorize the joins into 
these three types because they should be treated dif- 
ferently when query paths are considered. For example, 
a reference join should not be taken as a query path 
because if multiple entities reference to an entity, the 
referenced entity couW incorrectly relate the unrelated 
multiple entities to each other by a query path through 
the referenced entity. By identifying reference joins as 
such, query paths can easily avoid these joins. 
[0053] In addition, an entity may inherit Information 
from another entity using a technk^ue called subtyping. 
A subtype entity may be specializatkm of its supertype 
entity. For example, an entity Employee is a supertype 
entity for a subtype entity Salesman. Generally, a sub- 
type entity has more attributes than its supertype. In the 
above example, the entity Empkiyee may have at- 
tributes EmployeeNumber, Name, and Salary; and the 
entity Salesman may have attributes Quota, Sales and 
Commisskm in addition to EmpbyeeNumber. Name, 
and Salary. 

[0054] Entities and attributes in the business layer 
104 are given user friendly meaningful names. For ex- 
ample, the column named CUSTNAM from the CUST 
table in the data access layer 102 could be mapped to 
Customer Name attribute contained in the Customer 
Entity in the business layer 104. 
[0055] The ways of use of entity relationships in the 
metadata model 15 are different from those in conven- 
tional nrxxlelling tools. For example, in most Entity- Re- 
lationship (ER) nrxxJelling tods, the ER concept is used 
to provide an abstraction for defining a physbal data- 
base, i.e. , it is a different View' of the physk^al database. 
Within the metadata model 15, the business layer 104 
is used to provide an abstractbn for reporting data from 
physk^al data sources 100. 

[0056] The information of the objects of the business 
model in the business layer 104 is rtot generally availa- 
ble in underlying data sources 100. Usually available in- 
formation in metadata sources 101 is associated with 
the data access layer 1 02. rather than the business layer 
104. One thing that may be available In external meta- 
data repositories 101 is the business names for objects 
in the metadata model 1 5. However, again these busi- 
ness names tend to be provided for the physical tables 
and columns. If they can be mapped to the appropriate 
business entity or attribute, they may be used. 
[0057] The business rules are used to develop busi- 
ness intelligence applicatk>ns. Cabulations use a com- 
bination of attributes and expressbn components, and 
make them available to report so that the up-to-date and 
consistent definitbrrs are used to execute reports. 
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[0058] Fitters and prompts are used to restrict que- 
ries. Applying a filter to an entity or attribute limits the 
scope of data retrieval for all users who work with this 
entity or attribute. Applying a f ilterto an entity or attribute 
in conjunction with a user class limits the scope of data 
retrieval for the user class. Elements and styles are used 
to associate presentation information with an attribute. 
[0059] The package layer 106 contains a part of the 
model objects that describe subsets of the business lay- 
er 104. These model objects may be called package 
model objects. These are used to provkie an organized 
view of the information in the business layer 104. The 
information is organized in terms of business subject ar- 
eas or by way in which it is used. 
[0060] The package model objects in the package lay- 
er 106 include presentation folders and/or subjects. 
Each subject in the package layer 106 contains refer- 
ences to a subset of the business model objects that are 
interested in a particular group or class of users. The 
subset of the business model objects are reorganized 
so that they can be presented to the group of users in a 
way suitable to the group of users. Also, a user can com- 
bine references to the business model objects available 
from the business layer 104 into combinations that are 
frequently used in the user's business. User defined 
folders that contain these combinations of references 
are called user fokJers or presentation folders. 
[0061] PresentatkMi folders and subjects contain ref- 
erences to objects in the business layer 104, including 
entities, attributes, filters and prompts. Presentatbn 
folders create packages of information for the end user. 
Each package is definedfor a specific purpose, e.g., one 
or more business intelligence applrcations. Designers 
can combine them, by functions of subjects or by group 
of users, in order to organize business model objects 
into coilectbns of most frequently used objects, or in or- 
der to support varbus business intelligent tools or client 
applications using the reporting system 4 of the present 
inventkxi as a metadata provkJer. 
[0062] The information of the objects in the package 
layer 106 is not generally available in external data 
sources 100. The concept of organized business sub- 
ject areas may exist in external metadata repositories 
101 . The metadata model 15 may use such a concept 
in the business layer or data access layer. 
[0063] For all objects in the data access layer 1 02 and 
the business layer 104, business descriptive metadata 
may also be included. Business descriptive metadata is 
used to help understand the source and the meaning of 
the data which is being manipulated. Business descrip- 
tive metadata may include lineage, accuracy, descrip- 
tion and refresh rules. Lineage is a history of source and 
processing steps used to produce data set. Refresh is 
update rules for refreshing aggregated or submitted da- 
ta for reporting. Business descriptive metadata is used 
by an end user and an applicatkxi designer to under- 
stand the source of the information. Business descrip- 
tive metadata Includes such things as descriptbns and 



stewards. A steward is a person or group that manages 
the devek>pment, approval, creation, and use of data 
within a specified functional area. Business descriptive 
metadata may also include inf onnatbn that can be used 
s to relate the objects to information in external repositor- 
ies 101. 

[0064] Business descriptive metadata may exist In 
many forms In external repositories 101. General pur- 
pose repositories and business infomnation directories 

10 collect this information as that is their raison d'etre. 
Warehouse Extract -Transform-Load (ETL) tools collect 
this information as a result of collecting the ETL speci- 
fications. The information may be duplicated or collect- 
ed from a variety of sources in the metadata model 15 

IS so that it is available directly to the user as metadata. 
The metadata model 15 may also include context infor- 
matbn which can be used to retrieve information from 
external repositories 101. 

[0065] Most objects in the metadata nrKxiel 1 5 may be 
20 organized in a tree. Some objects model relationships 
between other objects. As described above, each busi- 
ness model object in the business layer 104 has a part- 
ner in the data access layer 102. This relatonship pro- 
vkJes the context for processing all the related informa- 
25 tion of the tables in the data access layer 102. For ex- 
ample, if a partk:ular column has not been processed, 
transfomnatkxis 20 process the column In the context of 
a parent relatbnship, i.e., build an attribute arKi put un- 
der the entity. 

30 [0066] The metadata model 15 may be built using 
CML files. CML files are compiled into C++ code which 
is then compiled in the reporting system 4 to build the 
metadata model 15. 



[0067] Referring back to Figure 2, COS 5 will now be 
described in further detail. COS 5 is not part of the meta- 
data rTKxJet 1 5. Rather, it provides a secure layer around 

^ the metadata model 1 5. Actions on objects in the meta- 
data model 15 cannot be performed without the involve- 
ment of COS 5. COS 5 communicates with the underly- 
ing repository where the metadata model 15 is stored. 
[0068] The metadata model 15 can be accessed by 

^ many users at the same time. Anything that a user wouW 
manipulate, such as an entity or an attribute, is repre- 
sented as an object in the metadata model 1 5. Each us- 
er may change objects or their properties, thereby 
changing the metadata model 1 5. Most of the objects in 

so the metadata model 1 5 are part of different kinds of re- 
lationships, and changes may cause inconsistency in 
the nnetadata model 1 5 If the changes are made without 
a mechanizm for providing consistency. 
[0069] COS 5 provides the means of presenting the 

55 semantic integrity of the metadata model 15. COS 5, 
provkies access to the objects within the repository 
where the metadata model 15 is stored; performs vali- 
datton checks, insuring precisk>n object storage; pro- 
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vides user security checks; oversees the changes to the 
objects; and participates in the creating of new object 
and deleting of existing ones. 
[0070] COS 5 provides each new object with a base 
ID. The base ID guarantees that the object can be found 
in the metadata model 15. The base ID is unique and 
stable for each object, i.e., it never changes. 
[0071 ] COS 5 also facilitates communication between 
the query engine 30 and the metadata model 15. 
[0072] The most important objects in COS 5 are, the 
gateway; the gateway broker; the gateway factory; and 
the transactnn. 

[0073] The gateway object is responsible for provid- 
ing secure access to the objects in the metadata model 
15. The gateway may be viewed as an intersection of 
the user and the repository. Multiple users can work with 
the same repository at the same time. Each such user 
will have one separate gateway to this particular repos- 
itory. A single user can work at the same time with mul- 
tiple repositories and have a separate gateway object 
for each repository. 

[0074] The gateway factory is a globally available sin- 
gle object responsible for creating and registering new 
repositories. 

[007SI The gateway broker is a globally available sin- 
gle object responsible for opening existing repositories, 
enumerating the registered repositor les, associating re- 
pository names with path/locatbns. 
[0076] The transactbn isolates the changes that the 
user makes to the objects of the metadata model 15. 
Thus, two or rrx^re users cannot make changes to the 
same repository objects simultaneously. 
[0077] There are three types of transactions, namely. 
Physical, Undo and Checkout. 

[0078] A checkout transaction is used to isolate 
changes made by one user from other users until those 
changes are complete. Checkout transactions can in- 
clude one object or many, depending on the task. 
Checkout transactions can last days, and spans multiple 
invocatkxis of the user interface. Any change to an ob- 
ject's state checks out the object automatbally. New ob- 
jects are checked out to the user that created them. 
[0079] If a user determines that a set of changes are 
valid, they may be checked in. A user may also discard 
any changes by un-checking his changes. 
[0080] Objects will be checked out automatically 
when the user attempts to change their state. When an 
object is checked out to a user, all other us ers will only 
be able to view this object in the way it was at the mo- 
ment of being checked out. Any attempt by other users 
to change, delete or check out an object already in the 
locked state due to another user action will fail. 
[0081] The object rtsetf is aware of the fact that it is 
being changed, and who is making the changes. Until 
the user makes a deciskxi to make the changes perma- 
nent and applies a check in method to the object in order 
to save these changes, the object is carrying around two 
data bkxks. The first data bkxk contains informatkxi in 



the original object status at the check out nrKxnent, and 
the second data bkx:k contains the changed object sta- 
tus. Once the object is checked in back to the repository, 
these changes contained in the second data block be- 
5 come permanent. The object in its brand new state be- 
comes visible and available for further possible actbns 
to all other users. 

[0082] A checkout transaction has two possible out- 
comes. If the user determines that the changes are cor- 

10 rect, they can be made permanent. In this case, the data 
bkxk that kept information about the original object's 
state is discarded. If the user determines that the chang- 
es are incorrect, or unwanted, they can be discarded, in 
which case the data bkx:k that kept information about 

IS the changes is discarded. 

[0083] An object that has not been checked out is con- 
skiered to be in the normal state, in which case it has 
the same content for all users. 
[0084] New objects are created such that they are 

20 considered checked -out by the user that created them, 
thereby making them visible to that user only. 
[0085] An object will be checked-out for a user when 
it is deleted, if necessary. An object that is checked-out 
by a user and deleted will not be visible to that user, but 

2S will remain visible to others until the checkout user 
checks-in the deleted object When the checkin occurs, 
the object is permanently renrxived from the repository. 
[0086] The undo transactk>ns altow users to undo 
changes to the repository during a single invocation of 

30 the user interface. This type of transaction is applicable 
to each bgical unit of work. Undo transactions are nest- 
ed inside checkout transactions. 
[0087] Physical transactbns are supplied by the re- 
pository. Because of the volume of objects that may be 

35 manipulated in a single Undo transaction, the Undo 
transaction Is typically subdivided into a series of phys- 
ical transactk>ns. 

[0088] There are two types of physical transactk>ns, 
namely, read- only and read-write. A read-only transac- 
40 tion provides readonly access to objects in the reposi- 
tory. A read-write transaction provides the user with the 
ability to change objects. 

[0089] All the changes are performed as a series of 
atomic consistent isolated durable (ACID) database 
45 transactkxis. 

[0090] Changes to an object may affect other objects 
based on the relationships that object has with other ob- 
jects in the rtKxJel. 

The user can check the integrity of the metadata model 
50 at any time by calling explk:itly the metadata check 
method. 

IP091] Thus, COS 5 maintains object persistence In 
the repository. COS 5 also performs house keeping and 
maintenance of objects as operations are performed, 
55 such as copy, paste, move, delete. COS 5 insures that 
these operatbns are executed in a consistent manner. 
[0092] COS 5 includes a modelling language, which 
is used to describe the objects stored in the repository 
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The modelling language reduces the amount of coding 
that required to be done. In the preferred embodiment, 
the modelling language produces C-i-«- code is used. 
COS 5 also provides transaction management and re- 
pository services. 

[0093] COS 5 defines proxy objects, which act as 
stand-ins for other repository objects in a specific con- 
text. Any modifications made to the original object are 
exposed through the proxy. The modelling language 
supports automatic generation of C++ ct asses that im- 
plement object proxies, saving the error-prone, tedious 
work manually writing this code. 
[0094] While the present invention has been de- 
scribed in connection with what is presently considered 
to be the most practical and preferred embodiments, it 
is to be understood that the invention is not limited to 
the disclosed embodiments. To the contrary, the present 
invention is intended to cover various rrKxJif ications, var- 
iations, adaptations and equivalent arrangements in- 
cluded within the spirit and the scope of the appended 
claims. The scope of the claims is to be accorded the 
broadest Interpretation so as to encompass all such 
modifications and equivalent structures and functions. 



Claims 

1 . A metadata model defining model objects to repre- 
sent one or more data sources, the metadata model 
comprising: 

a data access layer containing data access 
rTKKiel objects, the data access model objects 
including a data access rrxxlel object that de- 
scribes how to retrieve data from the data 
sources; 

a business layer containing business model ob- 
jects, the business model objects including a 
business model object that describes a busi- 
ness view of data in the data sources; and a 
package layer containing package rrxxJel ob- 
jects, the package model objects including a 
package model object which reference subsets 
of business rrxxiel objects. 

2. The metadata rrxxlel as claimed in claim 1 , wherein 
the data access model objects include a data ac- 
cess nrKXIel object that is constructed from metada- 
ta in the data sources. 

3. The metadata model as claimed in claim 1 , wherein 
the business model objects include a business 
model object that is transformed from the data ac- 
cess object. 

4. The metadata model as claimed in claim 1 , wherein 
the business model objects include a business 
model object that is imported from a metadata re- 



pository. 

5. The metadata model as claimed in claim 1 , wherein 
a business model object describes a business rule. 

5 

6. The metadata model as claimed in claim 5. wherein 
the business model object that describes a busi- 
ness rule is a calculat»n. 

10 7. The metadata model as claimed in claim 5, wherein 
the business model object that describes a busi- 
ness rule is a filter 

8. The metadata model as claimed in claim 5, wherein 
IS the business model object tfiat describes a busi- 
ness rule is a prompt. 

9. The metadata model as claimed In claim 1 , wherein 
a business model object describes a display rule. 

20 

10. The metadata model as claimed in claim 9, wherein 
a business model object that describes a display 
rule is a display style. 

25 11. The metadata model as claimed in claim 1 , wherein 
the package model objects include a package mod- 
el object that is imported from a metadata reposi- 
tory. 

30 12. The metadata model as claimed in claim 1 , wherein 
the data sources include a database that contains 
a table having columns; 

the data access model objects include table ob- 
3S jects that describe definitions of the tables con- 

tained in the data sources, and column objects 
that describe definitions of the columns of the 
tables contained in the data sources; and 
the business model objects include entities that 
40 are constructed based on the table objects in 

the data access layer, and attributes that are 
constructed based on the column objects in the 
data access layer 

45 13. The metadata model as claimed in claim 1 , wherein 
the data sources include one or more files; 

the data access nrKxiel objects include file ob- 
jects that describe definitions of the files con- 
50 tained in the data sources; and 

the business model objects include entities that 
are constructed based on the file objects in the 
data access layer. 

55 14. The metadata model as claimed in claim 1 , wherein 
the data sources include one or more cubes; 

the data access model objects include cube ob- 
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jects that describe definitions of the cubes con- 
tained in the data sources; and 
the business model objects include entities that 
are constructed based on the cube objects in 
the data access layer. s 

15. A metadata model containing rrxxiel objects repre- 
senting one or more data sources, the data sources 
containing tables having columns, the metadata 
model comprising: io 



16. The metadata model as claimed in claim 1 5, where- oo 
in the data access model objects further include a 
data access join that describe relationship between 
multiple table objects. 

17. The metadata model as claimed in claim 1 5, where- 35 
in the data access model objects further include a 
data access key that Is a collection of columns 
whose composite value is distinct for all rows in a 
table in the data sources. 

40 

1 8. The metadata OKxiet as claimed in claim 1 7, where- 
in the business model objects further include a busi- 
ness key that is constructed based on the data ac- 
cess key. 

45 

19. The metadata model as claimed in claim 1 5» where- 
in the business nrKxIet objects further Include a busi- 
ness join that describe relationship between multi- 
ple entities. 

SO 

20. The metadata OKxiel as claimed in claim 1 9, where- 
in the business join is a containment join represent- 
ing a strong relationship between entities. 

21. The metadata model as claimed in claim 19, where- ^ 
in the business join is a reference join representing 

a relationship between entities, one of which enti- 
ties functions as a kx>k-up table. 



22. The metadata model as claimed in claim 1 5, where- 
in the business model objects further include a sub- 
type relationship that defines an inheritance rela- 
tionship between two business entities. 

23. The metadata model as claimed in claim 1 5, where- 
in the data sources further include one or more 
views, and 

the data access layer contains table objects 
that are created based on definitbns of the views 
and a list of columns that is obtained from the views 
included in the data sources. 

24. The metadata model as claimed in claim 1 5, where- 
in the data sources further include one or more 
stored procedures, and 

the data access layer contains a list of col- 
umns that is obtained from the stored procedures 
included in the data sources. 



40 



45 



a data access layer containing data access 
model objects, the data access model objects 
including table objects that describe definitions 
of the tables contained in the data sources, and is 
column objects that describe definitions of the 
columns of the tables contained in the data 
sources; 

a business layer containing business model ob- 
jects, the business model objects including en- 20 
titles that are constructed based on the table 
objects in the data access layer, and attributes 
that are constructed based on the column ob- 
jects in the data access layer; and 
a package layer containing package nrxxiel ob- 2S 
jects, the package model objects including a 
package model object that defines a subset of 
the business modef objects. 
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